home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d27 / discus3x.arc / 3X278.TXT next >
Text File  |  1991-12-04  |  4KB  |  69 lines
  1. Don't Panic - Yet.
  2.  
  3.      I work in a small data processing shop in Indianapolis.  Where we
  4. maintain data for the purpose of direct mailing.  On a daily
  5. basis our data entry staff makes accesses to fifty or sixty files
  6. for the purpose of updates to the mailing lists.  Our system contains
  7. somewhere in the neighborhood of 11,000 client mailing lists, very few
  8. of which are accessed on an every day basis.
  9.  
  10.      Our backup requirements suggested to us that use of the SAVCHGOBJ
  11. command would serve the purpose of daily backups.  In the event of a
  12. "crash", we would need only to restore last months save lib nonsys and
  13. then "apply" each of the 30 change tapes.  Sounds like a safe plan,
  14. and hundreds of 38/400 shops are using this technique, but what you are
  15. about to read may shock you.
  16.  
  17.      In early June of 1990, our S38 had a 3370 mod B12 crash in the HDA.
  18. Yes, on a scale of 1 to 10, its a 9; I figure it would only be worse if
  19. there were no backup tapes or, no system.  IBM to the rescue with a new
  20. HDA and the system is at best running.  Next day, restoring all of this
  21. mess begins.  The SAVLIB LIB(*NONSYS) runs smooth and by the end of the
  22. day all access paths are rebuilt, all 52,000.  Now restore the change
  23. tapes and everything is O.K., right?  Sorry folks, its not quite that
  24. easy.
  25.  
  26. P A N I C!
  27.  
  28.      I shall attempt to stay on the track of the problem here and not
  29. go off and attack "Big Blue".  Day two, first change tape applies first
  30. level of changes and all is O.K. until tape 2.  At this point we notice
  31. certain members are not being restored, in particular SOURCE members.
  32. Spending some time analyzing the error messages, we determine that the
  33. file member level IDs do not match.  Right to the point, there is no
  34. combination of parameters on the RSTOBJ command to get around this.
  35.  
  36.      Three days have passed and enter the IBM support center LVL 1.
  37. IBM show 1 hit on this problem, and resolving the problem is undocumented.
  38. We are now on our way up from level 1, next stop "development center".
  39. In less than an hour we are put in contact with one of the maintenance
  40. programmers that takes care of CPF, who in not such a polite manor tells
  41. us: "Save changed object does not update the last save date...". Argument
  42. begins, why is this true when the UPDHST(*YES) is specified, answer
  43. "... it is a design consideration."  IBM can offer no solution to the
  44. problem, other than, "it is a design consideration.", I say: "How #$%#@
  45. inconsiderate of IBM, to not document this in ANY manual!".
  46.  
  47.      Solution, 24hrs pass, all attempts at restoring the changed files,
  48. with out deleting the old version have failed.  The only visible solution
  49. would be to change the file member level ID, which can only be done by
  50. updating the last save history.  To do this on a global level, this would
  51. require another save of the object with SAVOBJ or SAVLIB.  We decide to
  52. make sure we hit all of them and do the SAVLIB using the nonsys parameter.
  53. There is a God, tape 2 applies all changes, but tape 3 will not apply
  54. correctly with out another 5hr save lib nonsys.  No better solution could
  55. be found, so we spent several days in the 24hr go change a tape mode.
  56.  
  57.      I guess the real solution to this problem is, design a better back
  58. up process.  Some day it will happen, an HDA will crash on your system.
  59. Make sure you don't end up in the same shape we were in, the support
  60. center will be of little assistance, other than to tell you, a hit
  61. on this problem occurred and that problem #3X278 has no documented fix.
  62. There is no fix if you make it that far.  Make sure your back up routine
  63. is updating the save history of all your objects.
  64.  
  65.           Jeff Price
  66.           Sr. Systems Analyst
  67.           Faris Mailing
  68.           [71601,3231]
  69.  ...... ... ...-....1200 N81N         ......................... ... ...-....1200 N81N         ......................... ... ...-....1200 N81N         ......................... ... ...-....1200 N81N         ......................... ... ...-....1200 N81N         ................